System And Method For Real Time Account and Account Number Generation Using Origination APIS

ABSTRACT

A system and method generate an account in real time in accordance with an application programming interface (API). The API contains parameter descriptions listing universal resource locator (URL) parameters associated with items. A format for implementing an http request to transmit data to in compliance with the defined format is disclosed. A transparent mode for transmitting a response to an http request transmitting data provides for the transmission of an extensible markup language (XML) formatted file communicating an outcome to the request.

BACKGROUND

Generally, providers of financial solutions benefit from lead generationin developing business. This is because lead generation drivesindividuals to financial services providers. Wholesalers, retailers, andother commercial establishments have a steady stream of customers whichmay desire financial solutions. Further, many of these customers arepart of the 70-80 million persons in the United States that do not havethe benefit of a bank account or credit card. Often the commercialestablishments are in a position to offer financial services becausetheir customers are using websites or are physically located in stores.Sometimes offering these financial services will help the commercialestablishment to sell additional products and services. For Example, astore may require a bank account, credit, debit, or prepaid card, topurchase a service, but a customer may not have a bank account, credit,debit, or prepaid card, even though he has available funds and a steadystream of income. Such a non-banked Applicant is not served. Absent afinancial service that would immediately provide the individual with anaccount the business may be lost. What is needed is a system and methodfor communicating lead generation between the commercial establishmentsand the providers of financial solutions with real-time account creationcapabilities.

The foregoing examples of the related art and limitations relatedtherewith are intended to be illustrative and not exclusive. Otherlimitations of the related art will be come apparent to those of skillin the art upon a reading of the specification and a study of thedrawings.

SUMMARY

The following embodiments and aspects thereof are described andillustrated in conjunction with systems, tools, and methods that aremeant to be exemplary and illustrative, not limiting in scope. Invarious embodiments, one or more of the above described problems havebeen reduced or eliminated, while other embodiments are directed toother improvements.

A novel system creates an account for an individual in real time byreceiving applicant data, associating the applicant with a bank accountfrom a pool of accounts and then providing the account number to theindividual. Advantageously, this allows for sales to take place wherenon-banked customers might otherwise be turned away. In the case that acommercial establishment requires a bank account, credit, debit, orprepaid card number for the completion of a transaction, a bank account,credit, debit, or prepaid card number can be immediately provided to thecommercial establishment without requiring the customer's interaction.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the inventions are illustrated in the figures. However,the embodiments and figures are illustrative rather than limiting; theyprovide examples of the inventions.

FIG. 1 depicts a diagram 100 of an example of a system for generating anaccount in real time.

FIG. 2 depicts a flowchart 200 of an example of a method for generatingan account in real time.

FIG. 3 depicts a flowchart 300 of an example of a method for generatingan account in real time.

FIG. 4 depicts a table 400 of an example of parameters that can be usedin creating an account in real time.

FIG. 5 depicts a flowchart 500 of an example of a method for generatingan account in real time.

DETAILED DESCRIPTION

In the following description, several specific details are presented toprovide a thorough understanding of embodiments of the invention. Oneskilled in the relevant art will recognize, however, that the inventioncan be practiced without one or more of the specific details, or incombination with other components, etc. In other instances, well-knownimplementations or operations are not shown or described in detail toavoid obscuring aspects of various embodiments of the invention.

A novel system and method create an account for an individual in realtime. A customer submits a request to a financial services provider foran account. The request includes applicant data describing the customercontaining parameters associated with items formatted in accordance withan application programming interface (API) for originating applicantdata. The financial services provider receives the request andassociates a bank account with the customer. Then the customer isprovided an American Banking Association (ABA) routing transit number(RTN) as well as a deposit account number. In addition a debit paymentcard having the ability to charge payments is provided. In anon-limiting embodiment, a Visa or MasterCard debit card is used.

FIG. 1 depicts a diagram 100 of an example of a system for generating anaccount in real time. Although this illustration depicts components asfunctionally separate, such depiction is merely for illustrativepurposes. Those skilled in the art know that the components portrayed inthis figure can be arbitrarily combined or divided into separatesoftware, firmware, and/or hardware components. Furthermore, suchcomponents, regardless of how they are combined or divided can executeon the same computing device or multiple computing devices, and whereinthe multiple computing devices can be connected by one or more networks.

In the example of FIG. 1, the system 100 includes bank A 102, bank B104, automated clearinghouse 106, commercial establishment 108,financial services provider server 110, terminal 112, and customer 114.Here customer 114 can electronically connect with commercialestablishment 108. Commercial establishment 108 requires a bank account,credit, debit, or prepaid card number for the electronic purchase ofgoods and services.

In a non-limiting example commercial establishment 108 is a companyrequiring a bank account, credit, debit, or prepaid card number for thesale of a cable TV service. Customer 114 would be turned away bycommercial establishment 108 in the absence of an account to use.However, here, it is possible for customer 114 to be directed tofinancial services provider server 110 with the option of creating anaccount in real time for use in purchasing goods and services fromcommercial establishment 108.

FIG. 2 depicts a flowchart 200 of an example of a method for generatingan account in real time. Although this figure depicts functional stepsin a particular order for purposes of illustration, the process is notlimited to any particular order or arrangement of steps. One skilled inthe art will appreciate that the various steps portrayed in this futurecould be omitted, rearranged, combined, and/or adapted in various ways.

In the example of FIG. 2, the flowchart starts at module 202 withreceiving a request for an application for an account includingapplicant data for the account wherein the applicant data is formattedaccording to an Origination API. An exemplary set of parameters for usein transmitting applicant data using a universal resource locator (URL)is given in FIG. 4. The parameters depicted in FIG. 4 are discussed indetail in reference to FIG. 4.

In the example of FIG. 2, the flowchart continues to module 204 withassociating a bank account with the account. A plurality of banks iscontemplated. It is possible to have a pool of accounts in whichaccounts at a bank A are reserved for a financial services provider.Similarly a pool of accounts at bank B is reserved as well. A financialservices provider may then associate an account with an applicant fromthe accounts available to it from bank A, bank B . . . through bank n.

In some embodiments a screening process may be used to exclude anyapplicants that do not successfully meet initial criteria. An example ofthis process includes: transmitting an applicant's identificationinformation to a credit reporting bureau for the purposes of identifyingthe applicant.

In a non-limiting example, the applicant data received is processedthrough the Office of Foreign Asset Control (OFAC) SpecificallyDesignated Nationals (SDN) database for exclusion from consideration foran account. Further, any potential matches of customers will return amatch code indicating which elements of the record matched, along withthe full record from the database to assist in further verification.Additionally, after receiving an authentication outcome from the creditreporting bureau, the financial services provider may run an additionalcheck against its internal application records using data from thecredit reporting bureau.

In the example of FIG. 2, the flowchart continues to module 206 withgenerating an account number for the account. This can be done in realtime using the Luhn algorithm, also known as the modulus 10 or mod 10algorithm, which is a checksum formula used to validate a variety ofidentification numbers, such as account numbers. The algorithm can beused to distinguish valid numbers from collections of random digits.

In the example of FIG. 2, the flowchart continues to module 208 withproviding the account number identifying the account.

In some embodiments a customer is using her own computing device. Thecomputing device operates a web browser. The customer uses the webbrowser to visit a commercial establishment online to purchase productsor services from their website. There the customer is confronted with apayment entry window presented by the commercial establishment. Thecustomer may be simultaneously presented with a link offering to createan account so that the customer may complete her purchase.

In some embodiments, executing a link on a commercial establishment webpage executes a program which transmits customer information to afinancial services provider. The customer information is informationthat was already entered in furtherance of purchasing products orservices obviating the need to re-enter it. Following the creation ofthe account, the account information may be automatically transmitted tothe commercial establishment and the transaction completed.

In some embodiments, a link on a web page offered by a commercialestablishment is provided concurrently with a request for payment.Following the link, the customer is provided with a data entry form forthe collection of information in creating an account. Once the accountinformation entered the information is transmitted to a financialservices provider for the creation of an account. Once the account iscreated the account information may be either presented to the customervia a web page, or automatically communicated to the commercialestablishment for purchase of the goods or services.

In some embodiments, a customer is located in a “brick and mortar” storeowned by a commercial establishment using a computing device which runsa program operable to communicate with a financial services provider torequest an account. The program is not a web browser, but is instead aprogram created at least in part for the purpose of gatheringinformation and transmitting it to a financial services provider forcreation of an account. A customer may enter the information and have anaccount generated. The newly generated account may be used to completetransactions with the commercial establishment while the customer isphysically located at the “brick and mortar” store. The customer mayreceive products or services before leaving the store.

In some embodiments a customer is located in a “brick and mortar” storeowned by a commercial establishment using a computing device having aweb browser to apply for an account. The customer may visit a web siteoperated by the commercial establishment. The customer may be presentedwith a payment entry window containing a link offering to create anaccount. Following this link the commercial establishment providesinformation to a financial services provider for the purposes ofcreating an account for the customer. The customer information isinformation that was already entered in furtherance of purchasingproducts or services obviating the need to re-enter it for the financialservices provider. Following the creation of the account, the accountinformation may be automatically transmitted to the commercialestablishment. The customer may then complete a transaction and isphysically provided the goods or services before exiting the store.

In some embodiments a customer is located in a “brick and mortar” storeowned by a commercial establishment using a computing device having aweb browser to apply for an Account. A link on a commercialestablishment web page is provided concurrently with a request forpayment. Following the link, the customer is provided with a data entryform for the collection of information in creating an account. Thecustomer enters account information. The account information istransmitted to a financial services provider for the creation of anaccount. Once the account is created the account information may beeither presented to the customer via a web page. The customer may thenprovide the information to the commercial establishment for completionof a transaction. The customer may then be physically provided goods orservices before exiting the store.

In some embodiments a customer is speaking with a customer servicerepresentative of a commercial establishment via telecommunication forthe purpose of purchasing a product or service. In a non-limitingexample, the customer calls a commercial establishment by telephone andoffers to buy an item. A customer service representative requestspayment information and offers to create an account that the customercan use to fulfill the payment information request. The customerresponds requesting an account and provides account information for thecreation of the account. The customer service representative for thecommercial establishment receives account information from the customerand transmits it to a financial services provider. The financialservices provider creates an account and transmits the information tothe customer service representative. The customer service representativethen completes a transaction using the newly created account andconfirms with the customer that she has successfully purchased therequested product or service. The customer service representative maythen provide the newly created account information to the customer.

In some embodiments transparent mode is observed. In transparent mode, atransparent mode parameter is set to “true.” Then instead of redirectingthe applicant to a new page, the financial services provider server willsend a file other than a web page communicating the response. Theresponse could be a file formatted for the extensible markup language(XML) which could have the following structure:

<ApplicationResult>   <Outcome>0</Outcome>  <DepositOutcome>0</DepositOutcome>   <TeleCheckReason>notauthorized...</TeleCheckReason>   <QCN>12345678901</QCN></ApplicationResult>The tags identified above can be set to various values to indicate theresults of the submission of applicant data. The following providenon-limiting examples of these results:Values for <Outcome> could be:

0 (Application has been accepted)

1 (Error in submitted data, application has not been processed)

2 (Problem processing the data, OK to try again later)

3 (Application declined)

Values for <DepositOutcome> could be:

0 (Deposit has been processed and approved)

1 (Technical problem, connection error, deposit has not been processed)

2 (Customer is not eligible for deposit)

3 (TeleCheck Declined, refer to TeleCheckReason tag)

4 (Other declined)

9 (No CC or ACH was submitted for processing)

Values for <QCN> are:

11-digit account number (if the application has been accepted)

Empty string (if the application has not been accepted)

FIG. 3 depicts a flowchart 300 of an example of a method for generatingan account in real time. Although this figure depicts functional stepsin a particular order for purposes of illustration, the process is notlimited to any particular order or arrangement of steps. One skilled inthe art will appreciate that the various steps portrayed in this futurecould be omitted, rearranged, combined, and/or adapted in various ways.

In the example of FIG. 3, the flowchart starts at module 302 with acustomer submitting a request to a processing system for an account.This could be done by the customer clicking on a link to a financialservices providers website to request a page where she can fill inapplicant data.

In the example of FIG. 3, the flowchart continues to module 304 with thecustomer sending in application data to the processing system. Once thecustomer has filled in applicant data, she can submit it to thefinancial services provider. In a non-limiting example, this could be bysubmitting a web form.

In the example of FIG. 3, the flowchart continues to decision module 306with determining whether or not the customer is approved. If the resultfrom determination module 306 is NO, then the module proceeds to module316 with declining the application. There the flowchart proceeds tomodule 318 with transmitting the decline to the customer. Then theflowchart terminates.

In the example of FIG. 3, if the result of decision module 306 is YES,then the flowchart proceeds to module 308 with transmitting a responseincluding an approval. An approval can be transmitted via a web page, oras discussed above, in transparent mode. The customer may be providedwith her account information.

In the example of FIG. 3, the flowchart proceeds to module 310 with thecustomer funding the account using e.g. an ACH direct deposit. A directdeposit could provide funds from another bank account to the customersnewly associated bank account.

In some embodiments module 310 contains 320, 322, and 324. In Module 320the customer is presented with a request for information necessary tomake a direct deposit. Such a request could be a web form containingfields directed to account information such as the percentage or amountof direct deposit to be made. From module 320, the flowchart proceeds tomodule 322 with receiving the customers direct deposit information to bedebited. From module 322 the flowchart proceeds to module 324 withfacilitating direct deposit into customer's bank account associated withthe financial services provider. In facilitating the direct deposit, thefinancial services provider instructs the customer's to deposit theamount or percentage of the customer's paycheck as specified by thecustomer in module 320.

In some embodiments, module 310 contains only module 324. Module 324facilitates direct deposit of the customer's paycheck into thecustomer's bank account associated with the financial services provider.In facilitating the direct deposit, the financial service providerinstructs the customer's employer to deposit an amount or percentage ofthe customer's paycheck as determined by the customer.

In the example of FIG. 3, the flowchart continues to module 312 with thecustomer accessing her funds e.g. by using a prepaid debit card. In thiscase, the customer is able to use the funds contained in the account topurchase goods and services. Advantageously, this allows the customer topurchase goods and services that the customer could not purchase withoutan account.

FIG. 4 depicts a table 400 of an example of parameters that can be usedin creating an account in real time. The Origination API includes theseparameters. “Required” indicated whether or not data must be present forthe applicant data to be accepted.

As examples of parameters the following items are the applicant data asnamed: First Name, Middle Name, Last Name, Email, Street Address, City,State, Zip, Birth Date, Social Security Number, Home Phone, Work Phone.

As examples of parameters Card Choice may reflect a decision by thecustomer as to which card she wants e.g. a Silver MasterCard, a BlackMastercard, a Black Visa, or a Pink Visa. Direct Deposit Available maybe set to “1” meaning direct deposit is available through an employer,“2” meaning direct deposit is available through a benefits provider,“10” meaning Direct Deposit is not available, “11” meaning customer isnot employed, “12” meaning customer does not know if the direct depositis available or not.

As examples of parameters, pCode is a field which can be set forinternal purposes having a format PxxxxCxxxxSxxxx. Sub Code is also afield which can be set for internal purposes. Affiliate can be set toinclude a referring entity so that credit can be given for leadgeneration where an Affiliate drives business to the financial servicesprovider. Media Channel can be used to identify a search engine or otherchannel e.g. Google search, Yahoo search. URL may be set to the fullsignup URL identifying the exact web location where the customer datawas collected. Issuing Bank is used to identify one of the plurality ofbanks which provide the pool of accounts from which to associate acustomer with. Transparent Mode may be set to true or false meaning thatif true, then there is no redirection of the customer to another page,and instead an XML response is returned to the applicant. If false, thenthe applicant is redirected to another page where she collects heraccount information.

In some embodiments get request URL (universal resource locator) can beformatted to transmit an applicant's application information byformatting the URL in accordance with the “parameter=” format. Underthis format, a parameter name is followed by the “=” sign which is thenfollowed by a unit of data corresponding to a parameter.

FIG. 5 depicts a flowchart 500 of an example of a method for generatingan account in real time. Although this figure depicts functional stepsin a particular order for purposes of illustration, the process is notlimited to any particular order or arrangement of steps. One skilled inthe art will appreciate that the various steps portrayed in this futurecould be omitted, rearranged, combined, and/or adapted in various ways.

It will be appreciated to those skilled in the art that the precedingexamples and embodiments are exemplary and not limiting to the scope ofthe present invention. It is intended that all permutations,enhancements, equivalents, and improvements thereto that are apparent tothose skilled in the art upon a reading of the specification and a studyof the drawings are included within the true spirit and scope of thepresent invention. It is therefore intended that the following appendedclaims include all such modifications, permutations, and equivalents asfall within the true spirit and scope of the present invention.

1. A method for completing a business transaction comprising: requestinga product or service from a commercial establishment; receiving apayment information request containing a link that offers to create apre-paid bank account that can be used to fulfill the paymentinformation request; following the link to receive application dataincluding a request for deposit information to provide funding to thebank account; providing the deposit information to fund the bankaccount; receiving an approval for the account from a financial servicesprovider wherein the financial services provider selects the bankaccount from a pool of accounts and account information is automaticallytransmitted to the commercial establishment for fulfillment of therequest for payment information; and receiving an approval of therequest for the product or service from the commercial establishment. 2.The method of claim 1 wherein the approval for the pre-paid bank accountis transmitted in transparent mode, wherein transparent mode includestransmitting a file other than a web page communicating the response. 3.The method of claim 1 further comprising collecting customer informationby directing a customer to a form for entering customer information; andtransmitting the customer information as applicant data to the financialservices provider.
 4. The method of claim 1 further comprisingtransmitting applicant data to the financial services provider whereinapplicant data is originally entered by the customer for purposes ofpurchasing a product or service obviating a need to re-enter the datafor submission to the financial services provider.
 5. The method ofclaim 1 wherein the pre-paid bank account information is furtherpresented to the customer as a web page following the approval.
 6. Themethod of claim 1 wherein a customer is using her own computing device.7. The method of claim 1 wherein a customer is using a computing devicelocated in a store owned by the commercial establishment.
 8. The methodof claim 7 wherein the customer is using a computing device operated bythe commercial establishment that runs a program which collectsinformation and transmits it to the financial services provider.
 9. Themethod of claim 1 wherein the payment information request is a web formand the account information is used to populate the payment informationrequest.
 10. The method of claim 1 wherein a debit card is associatedwith the account. 11-29. (canceled)
 30. A method for completing abusiness transaction comprising: transmitting, from a first computingsystem executing instructions on a processor to provide a web browser, arequest for product or service, the request transmitted bytelecommunication to a second computing system operated by a commercialestablishment; receiving a request for payment information along with anoffer to create a pre-paid bank account with a financial servicesprovider offering a debit card for the pre-paid bank account wherein thepre-paid bank account can be used to fulfill the payment request;transmitting account information including deposit information to thefinancial services provider for creation and funding of an account;receiving, at the first computing system a confirmation that the accountwas approved wherein newly created pre-paid bank account information isautomatically used to fulfill the request for payment information;receiving an approval of the request for the product or service from thecommercial establishment, and displaying the approval of the request forthe product via the Web browser provided by the first computing system.31. A method for completing a business transaction comprising:presenting a customer with a website including a product for sale from acommercial establishment, the product displayed on the website alongwith a link offering to create a pre-paid bank account having a debitcard, the bank account to be used to pay the commercial institution forthe product; in response to a request for an account received from thecustomer via the link, and without redirecting the customer away fromwebsite, automatically creating a pre-paid bank account for the customerusing information received from the customer including depositinformation to provide funding to the account; and transmitting anelectronic payment to the commercial establishment to complete a sale ofthe product from the commercial establishment to the customer, theelectronic payment debited from the account created for the customer.32. The method of claim 31 wherein the customer information is formattedaccording to an Origination Application Programmer Interface (API). 33.The method of claim 31 wherein the link offers to create an the pre-paidbank account to pay for the product.
 34. The method of claim 31 whereinthe account is selected from a pool of accounts reserved for associationupon request.
 35. The method of claim 31 wherein the customerinformation is transmitted to a credit reporting bureau to identify thecustomer.
 36. The method of claim 31, wherein the transmission of theelectronic payment is made in transparent mode, wherein transparent modeincludes transmitting a file other than a web page communicating theresponse.
 37. The method of claim 31, further comprising creating aphysical debit card for the customer to use in accessing the account;and sending the card to the customer.
 38. The method of claim 31,wherein the information received from the customer includes directdeposit information.
 39. The method of claim 31, wherein the customerinformation received from the customer is copied from informationtransmitted to the commercial institution.
 40. A method comprising:receiving a selection of a link offering to create a pre-paid bankaccount offering a debit card, the link indicating that the pre-paidbank account can be used to pay for an item; transmitting a request forapplication information to a customer for the creation of the pre-paidbank account offering a debit card, the request including instructionsto format a response to the request using an application programminginterface (API), the request displayed to the customer via a graphicalinterface of a first computing system having a processor and memory, thememory storing the request and instructions for displaying the request,the processor executing the instructions to display the request to thecustomer and to collect customer information for the response formattedto the API, the customer information collected and identified byparameters specified by the API, the customer information includingdeposit information; receiving the response from the customer, theresponse including customer information formatted to the API definingapplication parameters for the pre-paid bank account, the responseincluding deposit information for funding the pre-paid bank account, theresponse received at a second computing system including a secondprocessor and a second memory, the second memory storing instructionsfor the processing of the response; extracting information from theresponse for processing of the customer information, the customerinformation extracted from the application parameters specified by theAPI, the customer information including the deposit information, thecustomer information processed by the second computing system to approveor decline the pre-paid bank account for the customer, an approval atleast partially based on an approval of the deposit information; andtransmitting an outcome of the application and a deposit outcome of thedeposit information to the first computing system.
 41. The method ofclaim 40 further comprising processing the deposit information to anapproval, wherein the deposit outcome reflects a value specified by theAPI defining an approval of the deposit.
 42. The method of claim 40further comprising processing the deposit information to determine atechnical problem, wherein a value, designated by the API is transmittedas the deposit outcome specifying the determination of the technicalproblem.
 43. The method of claim 40 further comprising processing thedeposit information to determine that the customer is not eligible for adeposit, wherein the deposit outcome reflects a value specified by theAPI stating that the customer is not eligible.
 44. The method of claim40 further comprising processing the deposit information to determinethat the deposit is declined, wherein the deposit outcome reflects avalue denoted by the API specifying that the deposit is declined. 45.The method of claim 40 further comprising determining that no depositinformation was submitted, wherein the deposit outcome reflects a valuedenoted by the API specifying that no deposit information was submitted.46. The method of claim 40 further comprising transmitting an accountnumber to the customer along with an approval of the account, theaccount number identified by formatting specified by the API.